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It is important that engineering and management accept the need for an availability 
requirement that is derived with its influencing attributes. It is the intent of this paper to 
provide the visibility of relationships of these major attribute drivers (variables) to each 
other and the resultant system inherent availability. Also important to provide bounds of the 
variables providing engineering the insight required to control the system’s engineering 
solution, e.g., these influencing attributes become design requirements also. These variables 
will drive the need to provide integration of similar discipline functions or technology 
selection to allow control of the total parts count. The relationship of selecting a reliability 
requirement will place a constraint on parts count to achieve a given availability 
requirement or if allowed to increase the parts count will drive the system reliability 
requirement higher. They also provide the understanding for the relationship of mean repair 
time (or mean down time) to maintainability, e.g., accessibility for repair, and both the mean 
time between failure, e.g., reliability of hardware and availability. The concerns and 
importance of achieving a strong availability requirement is driven by the need for 
affordability, the choice of using the two launch solution for the single space application, or 
the need to control the spare parts count needed to support the long stay in either orbit or on 
the surface of the moon. Understanding the requirements before starting the architectural 
design concept will avoid considerable time and money required to iterate the design to meet 
the redesign and assessment process required to achieve the results required of the 
customer’s space transportation system. In fact the impact to the schedule to being able to 
deliver the system that meets the customer’s needs, goals, and objectives may cause the 
customer to compromise his desired operational goal and objectives resulting in considerable 
increased life cycle cost of the fielded space transportation system. 


Nomenclature 

A ; = inherent availability 

A„ = achieved availability 

A„ = operational availability 

MTBF = mean time between failure 

MTTR = mean time to repair 

X = failure rate or the reciprocal of the MTBF 

r = number of failures or repairs 

N = total parts count 

t = system exposure time 

Pr = probability 
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I. Introduction 

I T is essential that management and engineering understand the need for a derived availability requirement for the 
customer’s space transportation system. It is also essential to provide engineering and management the visibility 
of the several variables that determine availability required to enable a system’s key goals and objectives. This 
relationship of the variables driving the availability-capability needs must be understood by all decision makers 
involved. This paper will address the inherent availability which only addresses the mean downtime as that mean 
time to repair or the time to determine the failed article, remove it, install a replacement article, and verify the 
functionality of the repaired system. Also with inherent availability the mean uptime will only consider the mean 
time between failures (for example, another form of availability addresses mean time between maintenance that 
includes both preventive and corrective maintenance) that require the repair of the system to be functional. It is also 
essential that management and engineering understand all influencing attribute relationships to each other and to the 
resultant inherent-availability requirement. Fig.l illustrates the influences these attribute relationships to each other 
and to the resultant availability requirement. This visibility will provide the decision makers with the understanding 
necessary to place constraints on the design definition for the major drivers that will determine the inherent 
availability, safety, reliability, maintainability, and the life cycle cost of the fielded system provided to the customer. 
This inherent availability requirement may be driven by the need to use a multiple launch approach to placing 
humans on the moon or the desire to control the number of spare parts required to support long stays in either orbit 
or on the surface of the moon or mars. 



Figure 1. Availability influence diagram 


II. Background 

Availability is the probability that a repairable system is operational — thus, availability is a function of both 
reliability and maintainability. Reliability is the probability a system will perform its intended function without 
failure for a specified period of time under specified conditions. Maintainability is the probability of restoring or 
repairing a system within a period of time when maintenance is performed in accordance with prescribed 
procedures. 

Availability and not reliability addresses downtime (i.e., time for maintenance, repair, and replacement 
activities). As with reliability, availability can be either a demonstrated or predictive measure of performance. 
Demonstrated availability is simply (uptime) / (uptime + downtime). Predictive availability has three types, namely, 
at time t (point availability), over an interval from t, to t 2 (interval availability), or over the long run as t — ► co 
(steady-state availability). 

Steady-state availability has three common forms (with each depending on the definitions of uptime and 
downtime), namely, inherent availability (Ai), achieved availability (Aa), and operational availability (Ao). Inherent 
availability is based solely on the failure (reliability) distribution and the downtime (maintainability) distribution and 
is an important system parameter for concept-architectural-design definition through systems-trade studies. 

The maintainability parameter of inherent availability only accounts for the time to diagnose and locate the failed 
article, access and repair it, and verify the functionality of the repaired system. The maintainability parameter for 
achieved availability is the same as inherent availability except it includes the time for preventive maintenance. Last, 
the maintainability parameter for operational availability is the same as achieved availability except it includes the 
time for logistics and administrative delays. 


2 

American Institute of Aeronautics and Astronautics 

092407 



For the purpose of this paper we will only discuss inherent availability (Aj) as shown in Eq. 1, 

Ai = MTBF / (MTBF + MTTR) ( 1 ) 

where MTBF is the mean time between failure and MTTR is the mean time to repair. That is, MTBF is the average 
time between system failures (i.e., the average time the system performs its intended function), and MTTR is the 
average down time (i.e., the time to identify and access the failed article, repair or replace the article, and verify the 
functionality of the repaired system). Stating an availability requirement by itself will not accomplish the 
requirement’s intent. Why, because there are three major drivers that influence and enable the achievement of the 
availability requirement. These drivers are reliability, maintainability, and total parts count (formerly referred to as 
“system element count”). The availability requirement and the mentioned drivers must be developed and linked 
together to form interdependent requirements. The relationship of these drivers and the desired level of inherent 
availability must be understood by both engineering and management to systematically achieve the customer’s 
needs and goals. 


III. Understanding the Availability and its Drivers 

A. Inherent Availability and its Influencing Attributes 

We will address inherent availability from a design perspective. By emphasizing the importance of the key 
attributes that influence availability, we can control the need to perform unplanned work during long space missions 
or during the critical phases of the launch operation. Since inherent availability is a mathematical function of MTBF 
and MTTR, availability is determined by both parameters (drivers) and not one. Thus, reliability and its common 
metric (MTBF) do not equate to availability. As MTBF increases, upper-bound MTTR increases for lower-bound 
availability requirement. Therefore, if the mission cannot accommodate the amount of down time from the predicted 
MTTR requirement, there is a need for selecting a higher availability requirement. If the opposite approach is taken 
to reduce MTBF in order to reduce the allowable MTTR, the probability of the number of failures would increase 
resulting in more replacement parts and the same total down time. However, the impact to the mission will be much 
greater. That is, there would be a greater burden on logistics and higher life cycle cost due to the increased demand 
in providing more parts. Table 1 below illustrates this relationship between the requirements for MTTR and MTBF 
for different availability requirements. This table assumes there is one system element with a mission time of one 
unit (hours will be used in this paper) and with failures occurring at a constant rate. 

Table 1. Availability requirement as a function of the reliability requirement and maintainability 
requirement for a fixed mission time 


Availability (A) 


System 

90% 

94% 

98% 

99% 

99.50% 

99.90% 

Reliability 


0.9500 

2.17 

1.24 

0.40 

0.20 

0.10 

0.02 

0.9800 

5.50 

3.16 

1.01 

0.50 

0.25 

0.05 

0.9900 

11.06 

6.35 

2.03 

1.01 

0.50 

0.10 

0.9940 

18.46 

10.61 

3.39 

1.68 

0.84 

0.17 

0.9950 

22.17 

12.73 

4.07 

2.02 

1.00 

0.20 

0.9960 

27.72 

15.93 

5.09 

2.52 

1.25 

0.25 

0.9980 

55.50 

31.88 

10.19 

5.05 

2.51 

0.50 

0.9990 

111.06 

63.80 

20.40 

10.10 

5.02 

1.00 

0.9998 

555.50 

319.12 

102.03 

50.50 

25.12 

5.00 

0.9999 

1,111.06 

638.27 

204.07 

101.01 

50.25 

10.01 


MTTR (Hours) 


MTBF = 
-1/In R 
19.496 

49.498 

99.499 
166.166 

199.500 

249.500 

499.500 

999.500 

4999.500 

9999.500 


To understand the relationship between increased hardware failures and reduced reliability, we will examine the 
probability of failure, total parts count, and system reliability. The Poisson distribution can be used to predict the 
exact number of repair or failure events (r) in time period (t) of interest. However, it assumes each part has a 
constant repair or failure rate X (where X is the reciprocal of MTBF) and is immediately repaired or replaced. When 
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the forecast is to determine the likelihood of r or less number of failures, the cumulative Poisson distribution can be 
used to determine this probability (Pr) and is described in Eq 2 

L J (2) 

where r is the upper bound for the number of failures, N is the total parts count under consideration, X is the failure 
rate, and t is time period of interest. Using Eq. 2 and Table 2 illustrate the relationship between system complexity 
(parts count) and system reliability where Table 2 provides the visibility for the predicted probability of success of 
controlling the part failures during the period of time of interest. This methodology can be used during design for 
controlling predicted hardware failures. This methodology places a bound on parts count to system reliability being 
selected. 

Table 2. System Complexity (parts count) shown as a function system reliability and probability of 1 or 
less failures (events) per one hour time period (mission) 

IF: Proposed System Has Serial Element Count (N) = 2,000 

Mission Time (t) = 1 


Mission's Maximum Failure Count (r) = 1 


And: 

Then: 

Probability Of Success: Failure Count Is r Or Less During t For Various 
System Complexity Levels (N ref ) Based On ^ 

System 

Reliability 

(R) * 

System 

MTBF 

Element 
Failure Rate 

(*i) 

1,000 

1,500 

2,000 

2,500 

5,000 

10,000 

20.000 

0.940 

16.2 

3.0938E-05 

0.99953 

0.99896 

0.99816 

0.99716 

0.98920 

0.96096 

0.87189 

0.945 

17.7 

2.8285E-05 

0.99961 

0.99913 

0.99846 

0.99761 

0.99089 

0.96680 

0.88926 

0.950 

19.5 

2.5647E-05 

0.99968 

0.99928 

0.99873 

0.99803 

0.99245 

0.97223 

0.90585 

0.955 

21.7 

2.3022E-05 

0.99974 

0.99942 

0.99897 

0.99841 

0.99386 

0.97724 

0.92155 

0.960 

24.5 

2.041 IE-05 

0.99979 

0.99954 

0.99919 

0.99874 

0.99513 

0.98180 

0.93623 

0.965 

28.1 

1.7814E-05 

0.99984 

0.99965 

0.99938 

0.99904 

0.99626 

0.98590 

0.94977 

0.970 

32.8 

1.5230E-05 

0.99989 

0.99974 

0.99955 

0.99929 

0.99724 

0.98952 

0.96204 

0.975 

39.5 

1.2659E-05 

0.99992 

0.99982 

0.99968 

0.99951 

0.99808 

0.99263 

0.97288 

0.980 

49.5 

1.010 IE-05 

0.99995 

0.99989 

0.99980 

0.99969 

0.99877 

0.99523 

0.98214 

0.985 

66.2 

7.5568E-06 

0.99997 

0.99994 

0.99989 

0.99982 

0.99930 

0.99728 

0.98967 

0.990 

99.5 

5.0252E-06 

0.99999 

0.99997 

0.99995 

0.99992 

0.99969 

0.99878 

0.99528 


When evaluating total parts count, this can be considered in two different ways. If the concern is for 
affordability, the total parts count considers all components that could be considered to have a failure mode. Any 
part failure will result in added maintenance burden and result in added life cycle cost. However, if the concern is 
for achieving a successful launch on time or for the in-space application for long term space flight, only the critical 
components (parts) should be considered that would impact the successful mission accomplishment. Because of this 
difference in objectives, the designer will probably want to perform both evaluations to allow the achievement of 
both objectives which can be controlled and accomplished by the design process. These attribute relationships and 
availability can be made more visible by examining scenario examples. 


B. An example of Space Transportation Application 

Let’s work an example case through this process to allow better visibility of using these aids. Let’s assume for a 
repairable system the requirements are a 45-day period (1080 hours) with 0.98 system reliability, 98% system 
availability, and upper-bound MTTR at 216 hours. This 45-day target may represent a desired total time for 
receiving the hardware at the launch site, integrating the major elements, servicing the consumables, installing and 
connecting any ordinance, and launching the space transportation system into space (including approximately 20% 
for hardware replacement, e.g., MTTR). We can see from Table 3 that the upper bound MTTR for our example is 
1090.98 hours. However, we must either select a higher availability or lower system reliability since the calculated 
upper-bound MTTR greatly exceeds the 216-hour requirement. Again using Table 3 when we do not change the 
0.98 system reliability requirement, the availability requirement needs to be adjusted upwards to be ~ 99.9% 
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providing an upper-bound MTTR of 53.51 hours. The other option would be to reduce system reliability to 0.90 to 
retain the upper-bound MTTR requirement of 216 hours. However, when we select a lower reliability, we need to 
address the likelihood (probability) of experiencing additional hardware failures. It can be seen from Table 4 that the 
system complexity requirement would be constrained to - 10,765 critical parts count maximum at a 98% or better 
probability of success while predicting the failures to be 2 or less parts per event. However, the upper-bound MTTR 
for these 2 parts will only be ~ 209 hours to achieve the availability of 98%. This option can be compared to the 
reliability choice of 0.98 where the critical parts constraint would be - 56,125 vs. the 10,765 with the reliability 
reduction to 0.90. 


Table 3. Availability shown highlighted as a function of system reliability and mean time to repair in 
hours 

Availability (A) = Mean Time Between Failure (MTBF) / (MTBF + Mean Time To Repair (MTTR)) 

A = MTBF / (MTBF+MTTR) or MTTR = MTBF(1-A / A) t= | 1080 | Hours 

A family of curves can be created for A = 90% to 99.9% with Sys. Reliability (R) = 0.95 to 0.99996 
Then MTTR is calculated for @ each A value 


Availability (A) 


System 

90% 

98% 

99% 

99.50% 

99.90% 

99.98% 

99.996% 

Reliability 


0.9000 

1,138.95 

209.19 

103.54 

51.51 

10.26 

2.05 

0.410 

0.9800 

5,939.80 

1,090.98 

539.98 

268.63 

53.51 

10.69 

2.138 

0.9900 

11,939.90 

2,193.04 

1,085.45 

540.00 

107.57 

21.50 

4.299 

0.9940 

19,939.94 

3,662.44 

1,812.72 

901.81 

179.64 

35.90 

7.179 

0.9950 

23.939.95 

4,397.13 

2,176.36 

1,082.71 

215.68 

43.10 

8.619 

0.9960 

29,939.96 

5,499.18 

2,721.81 

1,354.07 

269.73 

53.90 

10.779 

0.9980 

59,939.98 

11,009.38 

5,449.09 

2,710.85 

540.00 

107.91 

21.579 

0.9990 

119,939.99 

22,029.79 

10,903.64 

5,424.42 

1,080.54 

215.94 

43.180 

0.9995 

239,939.99 

44,070.61 

21,812.73 

10,851.56 

2,161.62 

431.98 

86.382 

0.9998 

599,940.00 

110,193.06 

54,540.00 

27,132.96 

5,404.86 

1,080.11 

215.987 

0.9999 

1,199,940.00 

220,397.14 

109,085.45 

54,268.64 

10,810.27 

2,160.32 

431.996 


MTTR (Hours) 


MTBF = 
-t/ln R 

10250.52 

53458.18 

107459.10 

179459.46 

215459.55 

269459.64 

539459.82 

1079459.91 

2159459.95 

5399459.98 

10799459.99 


Again it can be seen from Table 4 that it may be desirable to increase system reliability if it is unreasonable to 
constrain the parts count below -56,125 with a probability of success greater than - 98%. If we select system 
reliability greater than 0.98 to accommodate an increased parts count constraint, we will again need to reassess the 
availability requirement value for 99.9% to retain the MTTR requirement to - 216 hours. Attention should be paid 
to the element (part) failure rate requirement to attain these system reliability values to assure they are obtainable. 


Table 4. System Complexity (parts count) constraint example shown as a function of system reliability 
(0.90 & 0.98) and 98% probability of success of controlling failures to 2 or less / event 

I F : Proposed System Has Serial Element Count (N) = 2,000 
Mission Time (t) = 1,080 


Mission's Maximum Failure Count (r) = 2 


And: 

Then: 

Probability Of Success: Failure Count Is r Or Less During t For Various 
System Complexity Levels (N rrf ) Based On X* 

System 

Reliability 

(R) 

System 

MTBF 

Element 
Failure Rate 

Oi) 

1,000 

1,500 

2,000 

2,500 

5,000 

10,765 

56,125 

0.900 

10,250.5 

4.8778E-08 

0.99998 

0.99992 

0.99982 

0.99965 

0.99750 

0.98001 

0.43297 

0.945 

19,091.3 

2.6190E-08 

1.00000 

0.99999 

0.99997 

0.99994 

0.99958 

0.99625 

0.78658 

0.950 

21,055.4 

2.3747E-08 

1.00000 

0.99999 

0.99998 

0.99996 

0.99968 

0.99714 

0.82389 

0.955 

23,455.9 

2.1317E-08 

1.00000 

0.99999 

0.99998 

0.99997 

0.99977 

0.99789 

0.85893 

0.960 

26,456.3 

1.8899E-08 

1.00000 

1.00000 

0.99999 

0.99998 

0.99984 

0.99850 

0.89107 

0.965 

30,313.9 

1.6494E-08 

1.00000 

1.00000 

0.99999 

0.99999 

0.99989 

0.99898 

0.91974 

0.970 

35,457.3 

1.4101E-08 

1.00000 

1.00000 

1.00000 

0.99999 

0.99993 

0.99935 

0.94438 

0.975 

42,657.7 

1.1721E-08 

1.00000 

1.00000 

1.00000 

0.99999 

0.99996 

0.99962 

0.96457 

0.980 

53,458.2 

9.353 IE-09 

1.00000 

1.00000 

1.00000 

1.00000 

0.99998 

0.99980 

0.98002 

0.985 

71,458.6 

6.997 IE-09 

1.00000 

1.00000 

1.00000 

1.00000 

0.99999 

0.99992 

0.99072 

0.990 

107,459.1 

4.6529E-09 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

0.99997 

0.99697 
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For the purposes of determining the availability of the system during a more critical time during the launch 
operation, we provide an assessment of the last 16 hours (two work shifts) of the total 45-day flow time by adjusting 
the value for t in our model to 16 hours. For this evaluation, select a system reliability of 0.98 and the availability of 
0.98% with an upper-bound MTTR value of 5 hour for hardware replacement. It can be seen from Table 6 that a 
reliability value of 0.98 must be selected to achieve a one or less failure prediction within the 16 hours while 
constraining the critical parts count to 21,250 with minimum of a 0.98% probability of success. From Table 5 it can 
be determined with a system reliability value of 0.98 (MTBF of ~ 792 hours) that the availability must be 99.5% to 
constrain the MTTR to within the desired 5 hours. The first selected availability value of 0.98% would have allowed 
the MTTR of ~ 1 6 hours which is not compatible with our requirement. If it is desirable to increase the critical parts 
constraint above the 21,250, the system reliability requirement may need to be raised to 0.99 at an availability 
requirement of 99.9% to allow constraining the parts failure potential to one element (part) during this final 16 hour 
with a maximum of - 5 hours for this repair. 


Table 5. Availability shown highlighted as a function of system reliability and mean time to repair in 
hours 

Availability (A) = Mean Time Between Failure (MTBF) / (MTBF + Mean Time To Repair (MTTR)) 

A = MTBF / (MTBF+MTTR) or MTTR = MTBF(1-A / A) t= | 16 | Hours 

A family of curves can be created for A = 90% to 99.9% with Sys. Reliability (R) = 0.95 to 0.99996 
Then MTTR is calculated for @ each A value 


Availability (A) 


System 

90% 

98% 

99% 

99.50% 

99.90% 

99.97% 

99.994% 

Reliability 


0.9500 

34.66 

6.37 

3.15 

1.57 

0.31 

0.09 

0.02 

0.9800 

88.00 

16.16 

8.00 

3.98 

0.79 

0.24 

0.05 

0.9900 

176.89 

32.49 

16.08 

8.00 

1.59 

0.48 

0.10 

0.9940 

295.41 

54.26 

26.86 

13.36 

2.66 

0.80 

0.16 

0.9950 

354.67 

65.14 

32.24 

16.04 

3.20 

0.96 

0.19 

0.9960 

443.55 

81.47 

40.32 

20.06 

4.00 

1.20 

0.24 

0.9980 

888.00 

163.10 

80.73 

40.16 

8.00 

2.40 

0.48 

0.9990 

1,776.89 

326.37 

161.54 

80.36 

16.01 

4.80 

0.96 

0.9998 

8,888.00 

1,632.49 

808.00 

401.97 

80.07 

24.00 

4.80 

0.99990 

17,776.89 

3,265.14 

1,616.08 

803.98 

160.15 

48.01 

9.60 


MTTR (Hours) 


MTBF = 
-t/ln R 

311.93 

791.97 

1591.99 
2658.66 

3191.99 

3991.99 

7992.00 

15992.00 

79992.00 

159992.00 


We have discovered from Tables 4 and 6 these element-failure rates may not be achievable; therefore, we will 
address this subject from another perspective. Using Table 7 we will assume a 2000-serial-element count for this 
example and select a reasonable element- failure rate to determine the System MTBF and our probability for success 
of achieving 98% or better for this 16 hour mission when allowing 1 or less failures to occur. From Table 7 it is 
determined that an availability value of 99% can be selected when considering the element-failure rate of 1.5E-06 
while accommodating the 5 hour MTTR requirement. However, from Table 6 we see that the maximum parts count 
is lowered to between 5,000-10,000 elements. 


6 

American Institute of Aeronautics and Astronautics 

092407 


Table 6. System Complexity (parts count) example shown as a function of system reliability (0.98) and 
98% probability of success of controlling failures to 1 or less per event in time (16 hours) 

IF: Proposed System Has Serial Element Count (N) = 2,000 

Mission Time (t) = 16 


Mission's Maximum Failure Count (r) = 1 


And: 

Then: 

Probability Of Success: Failure Count Is r Or Less During t For Various 
System Complexity Levels (N ref ) Based On ^ 

System 

Reliability 

(R) 

System 

MTBF 

Element 
Failure Rate 

GO 

1,000 

1,500 

2,000 

2,500 

5,000 

10,000 

21,250 

0.940 

258.6 

1.9336E-06 

0.99953 

0.99896 

0.99816 

0.99716 

0.98920 

0.96096 

0.85885 

0.945 

282.8 

1.7678E-06 

0.99961 

0.99913 

0.99846 

0.99761 

0.99089 

0.96680 

0.87775 

0.950 

311.9 

1.6029E-06 

0.99968 

0.99928 

0.99873 

0.99803 

0.99245 

0.97223 

0.89586 

0.955 

347.5 

1.4389E-06 

0.99974 

0.99942 

0.99897 

0.99841 

0.99386 

0.97724 

0.91305 

0.960 

391.9 

1.2757E-06 

0.99979 

0.99954 

0.99919 

0.99874 

0.99513 

0.98180 

0.92918 

0.965 

449.1 

1.1 133E-06 

0.99984 

0.99965 

0.99938 

0.99904 

0.99626 

0.98590 

0.94411 

0.970 

525.3 

9.5 185E-07 

0.99989 

0.99974 

0.99955 

0.99929 

0.99724 

0.98952 

0.95767 

0.975 

632.0 

7.91 18E-07 

0.99992 

0.99982 

0.99968 

0.99951 

0.99808 

0.99263 

0.96970 

0.980 

792.0 

6.3133E-07 

0.99995 

0.99989 

0.99980 

0.99969 

0.99877 

0.99523 

0.98001 

0.985 

1,058.6 

4.7230E-07 

0.99997 

0.99994 

0.99989 

0.99982 

0.99930 

0.99728 

0.98841 

0.990 

1,592.0 

3.1407E-07 

0.99999 

0.99997 

0.99995 

0.99992 

0.99969 

0.99878 

0.99469 


Table 7. Availability shown highlighted as a function of system reliability and mean time to repair in hours 


Availability (A) = Mean Time Between Failure (MTBF) / (MTBF + Mean Time To Repair (MTTR)) 


A = MTBF / (MTBF+MTTR) or MTTR = MTBF(1-A / A) t = 

N = 

A family of curves can be created for A = 99% to 99.999% with Sys. Reliability (R) = 0.90 to 0.99999 
Then MTTR is calculated @ each A value 
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Hours 


2,000 


Availability (A) 


Element Failure 

72.00% 98.50% 99.00% 99.50% 99.90% 99.95% 99.99% 

MTBF = 

Rate ( a ,) 

1.00E-07 

1.00E-06 

1.50E-06 

1.00E-05 

1.50E-05 

1.00E-04 

1.50E-04 

1.00E-03 


1 / N*a, 

5,000.00 

500.00 

333.33 

50.00 

33.33 

5.00 

3.33 

0.50 

1,944.44 

76.14 

50.51 

25.13 

5.01 

2.50 

0.50 

194.44 

7.61 

5.05 

2.51 

0.50 

0.25 

0.05 

129.63 

5.08 

3.37 

1.68 

0.33 

0.17 

0.03 

19.44 

0.76 

0.51 

0.25 

0.05 

0.03 

0.01 

12.96 

0.51 

0.34 

0.17 

0.03 

0.02 

0.00 

1.94 

0.08 

0.05 

0.03 

0.01 

0.00 

0.00 

1.30 

0.05 

0.03 

0.02 

0.00 

0.00 

0.00 

0.19 

0.01 

0.01 

0.00 

0.00 

0.00 

0.00 


MTTR (Hours) 


C. An example of long term In-Space Application 

Let us now look at an example of long-term exposure in space without the opportunity to provide re-supply of 
any hardware from earth. This might be considered as a trip to another planet like Mars where trip time may be 
approximately two years. First, we must develop the reliability and maintainability requirements for this application 
of - 17,600 hour mission. We will choose a desired system reliability of 0.98 with an availability of 99.99%. We can 
see from Table 8 that our upper-bound MTTR will be ~ 87 hours. However, we can be see from Table 9 that the 
total parts count must be constrained from 2000 to 4000 (reliability of 0.98 to 0.99) critical parts if we assume there 
are no failures allowed (Availability of 100%) and at a probability of success of 98% or better. But allowing for our 
availability goal of 99.99% with 5 or less failures, we can see from Table 10 that our probability of success is ~ 
100% based on using parts with an element-failure rate of 5.7394E-10. 
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Table 8. Availability shown highlighted as a function of system reliability and mean time to repair in 
hours 

Availability (A) = Mean Time Between Failure (MTBF) / (MTBF + Mean Time To Repair (MTTR)) 

A = MTBF / (MTBF+MTTR) or MTTR = MTBF(1-A / A) t= | 17600 H nours 

A family of curves can be created for A = 99% to 99.999% with Sys. Reliability (R) = 0.90 to 0.99999 
Then MTTR is calculated @ each A value 


Availability (A) 


System 

99.000% 

99.500% 

99.900% 

99.950% 

99.990% 

99.995% 

99.999% 

Reliability 


0.90000 

1,687.33 

839.42 

167.21 

83.56 

16.71 

8.35 

1.67 

0.95000 

3,465.91 

1,724.25 

343.47 

171.65 

34.32 

17.16 

3.43 

0.98000 

8,799.70 

4,377.74 

872.04 

435.80 

87.13 

43.56 

8.71 

0.99000 

17,688.74 

8,799.93 

1,752.94 

876.03 

175.14 

87.56 

17.51 

0.99500 

35,466.59 

17,644.18 

3.514.71 

1,756.47 

351.15 

175.57 

35.11 

0.99990 

1.777,688.89 

884.377.89 

176,167.37 

88,039.62 

17,600.88 

8,800.00 

1,759.93 

0.99995 

3,555.466.67 

1,768,800.00 

352,343.54 

176,083.64 

35,202.64 

17,600.44 

3,519.95 

0.99999 

17,777,688.89 

8,844,176.88 

1,761,752.95 

880,435.82 

176,016.72 

88,003.96 

17,600.09 


MTTR (Hours) 


MTBF = 

-t/ln R 

167,045.50 

343,124.77 

871,170.37 

1,751,185.26 

3,511,192.65 

175,991,199.85 

351,991,199.93 

1,759,991.199.99 


Table 9. System Complexity (parts count) example shown as a function of system reliability at (0.98 to 

0.99) and 98% probability of success of controlling failures to 0 per event in time; however, the 
event time is long term in space of 2 years (17,600 hours). 

IF: Proposed System Has Serial Element Count (N) = 2,000 

Mission Time (t) = 17,600 


Mission's Maximum Failure Count (r) = 0 


And: 

Then: 

Probability Of Success: Failure Count Is r Or Less During t For Various 
System Complexity Levels (N ref ) Based On X, 

System 

Reliability 

(R) 

System 

MTBF 

Element 
Failure Rate 

W) 

L000 

1,500 

2,000 

2,500 

4,000 

10,000 

20,000 

0.940 

284,442.6 

1.7578E-09 

0.96954 

0.95465 

0.94000 

0.92557 

0.88360 

0.73390 

0.53862 

0.945 

311,117.0 

1.6071E-09 

0.97211 

0.95846 

0.94500 

0.93173 

0.89303 

0.75363 

0.56796 

0.950 

343,124.8 

1.4572E-09 

0.97468 

0.96226 

0.95000 

0.93790 

0.90250 

0.77378 

0.59874 

0.955 

382,243.6 

1.3081E-09 

0.97724 

0.96606 

0.95500 

0.94407 

0.91203 

0.79436 

0.63101 

0.960 

431,140.1 

1.1597E-09 

0.97980 

0.96985 

0.96000 

0.95025 

0.92160 

0.81537 

0.66483 

0.965 

494,004.9 

1.0121E-09 

0.98234 

0.97363 

0.96500 

0.95644 

0.93123 

0.83683 

0.70028 

0.970 

577,822.0 

8.6532E-10 

0.98489 

0.97741 

0.97000 

0.96264 

0.94090 

0.85873 

0.73742 

0.975 

695,162.9 

7.1926E-10 

0.98742 

0.98119 

0.97500 

0.96885 

0.95063 

0.88110 

0.77633 

0.980 

871,170.4 

5.7394E-10 

0.98995 

0.98496 

0.98000 

0.97506 

0.96040 

0.90392 

0.81707 

0.985 

1,164,511.2 

4.2936E-10 

0.99247 

0.98873 

0.98500 

0.98129 

0.97023 

0.92722 

0.85973 

0.990 

1,751,185.3 

2.8552E-10 

0.99499 

0.99249 

0.99000 

0.98752 

0.98010 

0.95099 

0.90438 
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Table 10. System Complexity (parts count) example shown as a function of system reliability at 0.98 and - 
100% probability of success of controlling failures to 5 or less per event in time; however, the 
event time is long term in space of 2 years (17,600 hours). 


IF: Proposed System Has Serial Element Count (N) = 2,000 

Mission Time (t) = 17,600 


Mission's Maximum Failure Count (r) = 5 


And: 

Then: 

Probability Of Success: Failure Count Is r Or Less During t For Various 
System Complexity Levels (N ref ) Based On X* 

System 

Reliability 

(R) 

System 

MTBF 

Element 
Failure Rate 
(Xi) 

1,000 

1,500 

2,000 

2,500 

5,000 

10,000 

20,000 

0.940 

284,442.6 

1.7578E-09 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

0.99995 

0.945 

311,117.0 

1.6071 E-09 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

0.99997 

0.950 

343,124.8 

1.4572E-09 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

0.99998 

0.955 

382,243.6 

1.3081 E-09 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

0.99999 

0.960 

431,140.1 

1. 1597E-09 

1.00000 

l. 00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

0.965 

494,004.9 

1.01 21 E-09 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

0.970 

577,822.0 

8.6532E-10 

1.00000 

1.00000 

l. 00000 

1.00000 

1.00000 

1.00000 

1.00000 

0.975 

695,162.9 

7.1926E-10 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

0.980 

871,170.4 

5.7394E-10 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

0.985 

1,164,511.2 

4.2936E-10 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

0.990 

1,751,185.3 

2.8552E-10 

l. 00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 


We have discovered these element-failure rates are most likely not achievable; therefore, we will address this 
subject from another perspective. Using Table 1 1 we will assume a 2000-serial-element count for this example and a 
list of reasonable element-failure rates to determine the System MTBF and our probability for success of achieving 
98% or better for this 17,600 hour (~ 2 years) mission when allowing 100 or less failures to occur. When 
considering a mission of this type, consideration should be given to accessibility to perform repairs; therefore, we 
should limit the capability to perform the repair (MTTR) in 2 hours maximum as a design requirement. Using Table 
12 we can see that the availability can be lowered to 72% to accommodate this 2 hour each repair) requirement 
while allowing for repairing up to 100 elements (parts) during the mission. 


Table 11. System Complexity (parts count) example shown as a function of element-failure rate (part 
reliability) at (1.0E-03 to 1.0E-8) and 98% probability of success of controlling failures to 100 or 
less per event in time; however, the event time is long term in space of 2 years (17,600 hours). 

IF: Proposed System Has Serial Element Count (N) = 2,000 

Mission Time (t) = 17,600 


Mission's Maximum Failure Count (r) = 100 


And: 

Then 


Probability Of Success: Failure Count Is r Or Less During t For Various 
System Complexity Levels (N ref ) Based On Xj 

Element 
Failure Rate 

(U) 

System MTBF 

System 

Reliability 

100 

300 

400 

500 

2,000 

3,000 

4,627 

1.0000E-03 

0.5 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

1.5000E-04 

3.3 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

I.0000E-04 

5.0 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

4.0000E-05 

12.5 

0.00000 

0.99965 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

0.00000 

1.5000E-05 

33.3 

0.00000 

1.00000 

0.98968 

0.31419 

0.00220 

0.00000 

0.00000 

0.00000 

L0000E-05 

50.0 

0.00000 

1.00000 

1.00000 

0.99965 

0.90660 

0.00000 

0.00000 

0.00000 

1.5000E-06 

333.3 

0.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

0.98968 

0.02242 : 

1.0000E-06 

500.0 

0.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

0.98007 

1.5000E-07 

3,333.3 

0.00509 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1 0000E-07 

5,000.0 

0.02960 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

I.0000E-08 

50,000.0 

0.70328 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 

1.00000 
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Table 12. Availability shown highlighted as a function of Element-failure rate (a*) and mean time repair 
in hours 

Availability (A) = Mean Time Between Failure (MTBF) / (MTBF + Mean Time To Repair (MTTR)) 


A = MTBF / (MTBF+MTTR) or MTTR = MTBF(1-A / A) 

A family of curves can be created for A = 99% to 99.999% with Sys. Reliability (R) 
Then MTTR is calculated @ each A value 


t = 
N 

= 0.90 to 0.99999 


17600 


Hours 


2000 


Availability (A) 


Element Failure 

72.00% 

98.50% 

99.00% 

99.50% 

99.90% 

99.95% 

99.99% 

Rate ( a ,) 




1.00E-07 

1,944.44 

76.14 

50.51 

25.13 

5.01 

2.50 

0.50 

1.00E-06 

194.44 

7.61 

5.05 

2.51 

0.50 

0.25 

0.05 

1.50E-06 

129.63 

5.08 

3.37 

1.68 

0.33 

0.17 

0.03 

1.00E-05 

19.44 

0.76 

0.51 

0.25 

0.05 

0.03 

0.01 

1.50E-05 

12.96 

0.51 

0.34 

0.17 

0.03 

0.02 

0.00 

1.00E-04 

1.94 

0.08 

0.05 

0.03 

0.01 

0.00 

0.00 

1.50E-04 

1.30 

0.05 

0.03 

0.02 

0.00 

0.00 

0.00 

1.00E-03 

0.19 

0.01 

0.01 

0.00 

0.00 

0.00 

0.00 


MTTR (Hours) 


MTBF = 
1 / N*a, 

5,000.00 

500.00 

333.33 

50.00 

33.33 

5.00 

3.33 

0.50 


IV. Conclusion 

The availability requirement must be worked by addressing the MTBF requirement, MTTR requirement, and the 
constraint on the number of critical-system elements (critical-parts count) for the system being designed. These 
requirements must be developed together and managed through out the design process with the understanding of 
their relationships. If a design-analysis-capability analysis such as the one discussed in this paper or the use of 
today’s reliability and maintainability tools are used in the design, development, and evaluation (DDT&E) phase, 
the availability requirement, the MTTR requirement, the MTBF requirement, probability of success, affordability, 
and safety can all be controlled by design. However, because of their relationships to each other, availability, 
reliability, maintainability, and total parts count must be worked and developed together to provide the correct 
understanding and control to meet all of the objectives. They also must be performed during concept development 
and available as requirement input before proceeding with the detailed design. 

Additional benefits can be achieved by selecting the best technologies that provide major reductions in total parts 
count. An example would be to select a direct-electro-mechanical control instead of using an intermediate fluid to 
perform the function while using the electro-mechanical device to control the intermediate fluid (e.g., electro- 
mechanical valve controlling fluid flow versus, a hydraulic or pneumatic operated valve while using a solenoid 
valve to control the hydraulic or pneumatic fluid which then controls the fluid valve. The use of common fluids for 
propulsion applications allowing an integrated system solution with only one fluid container would provide a major 
reduction in total parts count). When the criticality drives the design to provide redundant hardware solutions, the 
selection of hardware should always be at the best element reliability possible to provide the lowest maintenance 
burden for lowering life-cycle costs. In the provided example, additional benefits, the resultant DDT&E and 
operational cost will be reduced along with the achievement of the highest overall system reliability and safety and 
can achieve a higher availability of the system enabling mission success. 

In summary, system-development work that focuses on inherent reliability, MTBF with an emphasis on parts 
count, and maintainability will improve performance, safety, and operational affordability. Performance is improved 
when fewer and better parts are used as well as provide the additional benefit of less weight. Safety is improved as 
hardware that does not fail during integration, checkout, and servicing inevitably will perform better in actual use. 
Affordability is also improved with every improvement in inherent reliability, maintainability, and focusing on 
reduced parts count as better overall performance makes each flight more productive and allows for additional 
flights due to shorter process or production intervals. Ultimately, hardware that fails during processing, regardless of 
redundancies, will not function well in a long flight. All that is lacking for improved technology is the investment 
up-front (e.g., focus on improved generic technology that numerous subsequent users can take advantage of to 
justify their initial investment, such as the example of selecting the best technologies mention above). This payback 
could be across the entire economic growth perspective and not limited to a single system use. 
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Program Availability Requirements Relationships 

Overview of the ISSUE 


The following requirements from the CARD illustrate the need for a high Reliability 
and Available System Architecture for Lunar Operations. 

Availability is classically expressed in terms of Mean Time Between Failure (MTBF) 
and Mean Time To Repair (MTTR). 

Reliability can be expressed in terms of MTBF. 

Establishing availability requirements makes it necessary to define availability and 
reliability with the attributes listed above. [The CARD does not adequately describe 
availability because it does not couple it to both of the reliability attributes; therefore, 
inadequately describing availability in terms of percent.] 

The following analysis will: 

- Show why repair time must be considered in the development of the availability requirement. 

- Illustrate the sensitivity in specifying the correct values for all these attributes to achieve the 
program objectives. 

Recommendations are provided in this presentation for changing the CARD to 
include all the attributes required to define the Reliability and Availability 
Requirements 


2 


Example Constellation Level II (CARD) Requirement 
Rationale That Drives Reliability and Availability 

[CA5600-PO] RIDDABLE 

• The Constellation Architecture shall have an (TBD-001-517) % probability of launch per 
uncrewed launch attempt, starting at "LCC Call to Station" and ending at close of day of 
launch window. 

Rationale: The Lunar missions' success hinge on meeting very small Translunar Injection Windows of 
approximately 1 Low Earth Orbital pass per month. In order to be prepared to meet this tight 
window, both the uncrewed stack and the crewed stack must launch on time. Therefore, the 
uncrewed stack must demonstrate a High Launch Probability. This requirement decomposes into 
other launch availability requirements that need to be placed on the separate elements: CaLV 
hardware ready and LSAM hardware ready. Additionally, abort landing site weather and Launch 
site weather as well as the mission systems and ground systems readiness are contributing 
factors to the uncrewed stack launch probability. However, these are more constrained by the 
Crewed launch probability requirements than by this requirements. Therefore, these areas are not 
allocated as duplicative and less constraining requirements from this requirement. 

[CA5600V-PO] RIDDABLE 

• The ability of the Constellation Architecture to meet an (TBD-001 -51 7) probability of launch per 
crew launch attempt, starting at "LCC Call to Station" and ending at close of day of launch window 
shall be verified by analysis. The verification analysis shall use only R&M Panel approved data 
sources for MTBF and MTTR and shall be performed in accordance with the CxP Reliability and 
Maintenance Plan (CxP 700879). Verification shall be considered successful when analysis 
shows that the probability of launch per crew launch attempt is at least (TBD-001-517)) with an 
uncertainty of not greater than (TBD-001 -631). 
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Program Availability Requirements Relationships 

INTRODUCTION of ISSUE 

Constellation Program Availability Requirements Relationships 

• BACKGROUND: An Availability Requirement by itself will not accomplish its intended 
function. Reference the CARD Paragraph 3.2.12 Reliability and Availability 


CARD Definitio 

n for the term: AVAILABILITY 

Availability 

A measure of the degree to which an item is in an operable 
state and can be committed for immediate use. 


• Definition in Simple language: Availability is a function of the planned event flow, 
probability of failure to accomplish that flow, and the time required to repair. 

• Availability (A) = Mean Time Between Failure (MTBF) / [(MTBF) + Mean Time To 
Repair (MTTR)] 

• Therefore: Stating an availability requirement by itself will not accomplish the 
intended simple requirement. 

• To enable this requirement : The Program must provide the flow-down requirements 
to control failure probability (MTBF) and the system repair time (MTTR) in the event 
of failure during the intended time period. Requirements change must start with the 
Program Level II CARD and flow through the Program’s Level III and Level IV 
requirements documents down to and including the system end-item specifications. 
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Program Availability Requirements Relationships 

CARD Availability Requirement 

• Constellation Architecture Requirements Document (CARD) CxP 70000 

- Paragraph 3.2.12 Reliability and Availability 

- The Constellation Architecture system shall have an 88% (TBR-001 -021 ) 
probability of launch per crew launch attempt, starting at "LCC Call to Station" 
and ending at close of day-of-launch window. 


Table 4 - Launch Probability and Contributing Conditional Probabilities 



Crewed Launch 

Cargo Launch 

Net Probability of Launch:* 

*Range Safety Probability excluded 

0.88 (TBR-001-021) 

(TBD-00 1-064) 

Contributing Conditional Probabilities: 



CEV hardware availability 

0.98 (TBR-001-021) 

(TBD-00 1-064) 

CEV probability of meeting abort zone weather 
constraints 

0.98 (TBR-001-021) 

(TBD-00 1-064) 

CLV hardware availability 

0.98 (TBR-001-021) 

N/A 

CLV probability of meeting launch site weather 
constraints 

0.95 (TBR-001-021) 

N/A 

MS hardware / system availability 

TBD (TBR-001-021) 

(TBD-00 1-064) 

GS hardware / system availability 

TBD (TBR-001-021) 

(TBD-00 1-064) 

CaLV hardware availability 

N/A 

(TBD-00 1-064) 

CaLV probability of meeting launch site weather 

N/A 

(TBD-00 1-064) 


constraints 

Probability of meeting Range Safety Constraints 































Program Availability Requirements Relationships 

Discussion of Requirements With Insufficient Attributes 

Develop the case using the Level II CARD requirements with the aid of Generic Reliability and 
Availability tools developed for deriving requirements to enable meeting the program objectives. 

(These new tools were developed for the purpose of communicating the Availability attribute 
relationships as well as the establishment of mathematical requirements needed to enable the 
Program objectives.) 

- The CARD requires a crewed launch net probability of 88% with a CLV probability of meeting 
launch site weather constraints of 95% 

- The CEV and CLV hardware availability of 98% 

- The MS & GS hardware / system availability is TBD 

Select the CARD availability requirement of 98% and determine with the aid of the Generic 
Reliability and Availability tools what the MTBF & MTTR values should be: from the charts 7 & 13 
it can be determined that the Availability value alone will not determine the MTBF or the MTTR 
when expressed in % of MTBF (does not discriminate between different Reliability values), but 
establishes the relationship of the MTTR to be -2% of the MTBF. Therefore, let us examine the 
CLV intended MTBF of 1000 hours (Systems reliability will be 0.999) and determine from the chart 
that the MTTR to be -2% of MTBF or -20 hours. This 20 hours exceeds the CLV stated MTTR 
target of 12 hours. From the chart, this MTTR of 12 hours is equivalent to an availability of -99%. 
However, this assessment assumes the MTBF for the event to be the entire 1000 hours. 


Now let us examine the CEV’s desired 208 days (4992 hours) for the MTBF (Using the MTBF 
formula on the chart the Systems Reliability is -0.9998) and determine from the chart that the 
MTTR will be -2% of MTBF or 96 hours with an availability requirement of 98%. This MTTR of 96 
hours (4 days) will result in a month delay for the CEV launch for EDS rendezvous when applying 
the failure event time to the entire 208 days. 

The above two example MTTR results suggests a low probability of supporting the objective of 
launch on time need for the Lunar program and also shows MTTR does not change with respect 
to reliability when expressed in percent of MTBF (This relationship will be discussed later). 6 



Program Availability Requirements Relationships 

For MTTR and System Reliability Where MTBF = -1 / In R 

Availability (A) = Mean Time Between Failure (MTBF) / (MTBF + Mean Time To Repair (MTTR)) 

or 

A = MTBF / (MTBF+MTTR) or MTTR = MTBF/(A - MTBF) 

A family of curves can be created for A = 90% to 99.9% with System Reliability (R) = 0.95 to 0.9999 
Then MTTR = % MTBF @ each A value 


Availability (A) 


System 

90% 

91% 

92% 

93% 

94% 

95% 

96% 

97% 

98% 

99% 

99.50% 

99.90% 

Reliability 













0.9500 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9600 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9700 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9800 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9900 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9910 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9920 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9930 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9940 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9950 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9960 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9970 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9980 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9990 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 

0.9999 

11.1111% 

9.8901% 

8.6957% 

7.5269% 

6.3830% 

5.2632% 

4.1667% 

3.0928% 

2.0408% 

1.0101% 

0.5025% 

0.1001% 


MTTR 

(in % MTBF) 



Specifying one parameter implies requirements on the other two variables 


Examples: 

Assume the MTBF is 1000 hours (R=0.999), with an 
availability (A) of .98, then the MTTR would be 1000 x 
2.0408% = to -20.41 hours 

Assume the desired MTTR is 4 hours with an availability of 
.98, then the MTBF would be 199.4996 hours @ R of 0.995 
Requirement Development: Use MTBF of 1000 hours 
(R=0.999) and MTTR of 5 hour to support the CTS Lunar 
launch case; therefore, A = 0.995% 


We Must Get This Right for Mission Success 


MTBF 
= -1/In R 

19.49573 

24.4966 

32.8308 

49.49832 

99.49916 

110.6104 

124.4993 

142.3566 

166.1662 

199.4996 

249.4997 
332.8331 

499.4998 

999.4999 
9999.5 
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Program Availability Requirements Relationships 
Discussion of Proper Requirements With Appropriate Attributes 

• Start with the program need to achieve its objectives of launch on time and if launch 
isn’t achieved on 1 st attempt, preserve the 24 hour turnaround. This should drive the 
MTTR. For this discussion our target will be 4-5 hours. 

- Assume the program’s objective for the CLV is to achieve 1000 hour for its MTBF 
(equivalent to a System’s Reliability of 0.999) 

- Therefore, from chart 12, the availability requirement must be 99.5% = ~5 hours 

- Now assume the program’s objective for the CEV is to achieve 208 days or 4992 
hours for its MTBF (equivalent to a Systems Reliability of -0.9998) 

- Therefore, from chart 12, the availability requirement must be -99.9% 

- However, when considering the hardware probability of failure of less than 5%, 
from charts 14 & 15, and to not over constrain the hardware parts count, this 
would suggest choosing the Systems Reliability value from an assessment of the 
System’s Complexity, e.g., with System Reliability of 0.9999, the total active 
components count should be constrained to -3,300 or less or if the Systems 
Reliability is established at 0.999 (CLV value), the total active components count 
should be constrained to~350 or less. This assessment assumes 1 or less 
failures per event and assumes the MTBF to be the entire 1000 hours. 

- This “Probability of Failure Relationship for System Complexity and System 
Reliability” using the active tool (product of assessment on chart 14) can be used 
for all Systems of the program including the Ground Systems, while considering 
it as a reusable system. 
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Program Availability Requirements Relationships 
Discussion of Proper Requirements With Appropriate Attributes Continued 

Select MTBF of interest, “call to station until launch” (72 hrs.), and failure rate of zero (0) 

• With CEV MTBF of 208 days (4992 hours), driven by mission length, and CARD 
requirement of 88% probability of success of launch on time, the table below (see 
chart 22) shows that CEV’s active parts are constrained to -40,000 

• With CARD Availability of 0.98, the calculated MTTR would only be ~1 .5 hours for 
performing any corrective action during the 72 hours prior to launch. 

• However, if probability of success = 95%, CEV complexity must be reduced by -60%, 
i.e., total active parts count are constrained to between 10,000 and 20,000 = -16500 

System Complexity (Parts Count (N)) 


System 
Reliability (R) 

(L)=1-R 

40000 

20000 

10000 

5000 

2000 

1000 

500 

400 

300 

200 

100 

50 

25 

0.9500 

0.0500 

100.0000% 

100.0000% 

99.9447% 

97.6482% 

77.6870% 

52.7633% 

31.2711% 

25.9182% 

20.1484% 

13.9292% 

7.2257% 

3.6806% 

1.8575% 

0.9600 

0.0400 

100.0000% 

99.9994% 

99.7521% 

95.0213% 

69.8806% 

45.1188% 

25.9182% 

21.3372% 

16.4730% 

11.3080% 

5.8235% 

2.9554% 

1.4888% 

0.9700 

0.0300 

100.0000% 

99.9877% 

98.8891% 

89.4601% 

59.3430% 

36.2372% 

20.1484% 

16.4730% 

12.6284% 

8.6069% 

4.4003% 

2.2249% 

1.1187% 

0.9800 

0.0200 

99.9994% 

99.7521% 

95.0213% 

77.6870% 

45.1188% 

25.9182% 

13.9292% 

11.3080% 

8.6069% 

5.8235% 

2.9554% 

1.4888% 

0.7472% 

0.9900 

0.0100 

99.7521% 

95.0213% 

77.6870% 

52.7633% 

25.9182% 

13.9292% 

7.2257% 

5.8235% 

4.4003% 

2.9554% 

1.4888% 

0.7472% 

0.3743% 

0.9910 

0.0090 

99.5483% 

93.2794% 

74.0760% 

49.0844% 

23.6621% 

12.6284% 

6.5272% 

5.2568% 

3.9691% 

2.6639% 

1.3409% 

0.6727% 

0.3369% 

0.9920 

0.0080 

99.1770% 

90.9282% 

69.8806% 

45.1188% 

21.3372% 

11.3080% 

5.8235% 

4.6866% 

3.5360% 

2.3714% 

1.1928% 

0.5982% 

0.2996% 

0.9930 

0.0070 

98.5004% 

87.7544% 

65.0062% 

40.8445% 

18.9416% 

9.9675% 

5.1146% 

4.1130% 

3.1009% 

2.0781% 

1.0445% 

0.5236% 

0.2622% 

0.9940 

0.0060 

97.2676% 

83.4701% 

59.3430% 

36.2372% 

16.4730% 

8.6069% 

4.4003% 

3.5360% 

2.6639% 

1.7839% 

0.8960% 

0.4490% 

0.2247% 

0.9950 

0.0050 

95.0213% 

77.6870% 

52.7633% 

31.2711% 

13.9292% 

7.2257% 

3.6806% 

2.9554% 

2.2249% 

1.4888% 

0.7472% 

0.3743% 

0.1873% 

0.9960 

0.0040 

90.9282% 

69.8806% 

45.1188% 

25.9182% 

11.3080% 

5.8235% 

2.9554% 

2.3714% 

1.7839% 

1.1928% 

0.5982% 

0.2996% 

0.1499% 

0.9970 

0.0030 

83.4701% 

59.3430% 

36.2372% 

20.1484% 

8.6069% 

4.4003% 

2.2249% 

1.7839% 

1.3409% 

0.8960% 

0.4490% 

0.2247% 

0.1124% 

0.9980 

0.0020 

69.8806% 

45.1188% 

25.9182% 

13.9292% 

5.8235% 

2.9554% 

1.4888% 

1.1928% 

0.8960% 

0.5982% 

0.2996% 

0.1499% 

0.0750% 

0.9990 

0.0010 

45.1188% 

25.9182% 

13.9292% 

7.2257%r 

2.9554% 

1.4888% 

0.7472% 

0.5982% 

0.4490% 

0.2996% 

0.1499% 

0.0750% 

0.0375% 

0.9998 

0.0002 

11.3080% 

5.8235%r 

2.9554% 

1.4888% 

0.5982% 

0.2996% 

0.1499% 

0.1199% 

0.0900% 

0.0600% 

0.0300% 

0.0150% 

0.0075% 

0.9999 

0.0001 

5.8235%f 

2.9554% 

1.4888% 

0.7472% 

0.2996% 

0.1499% 

0.0750% 

0.0600% 

0.0450% 

0.0300% 

0.0150% 

0.0075% 

0.0037% 


Probability of Success is Highly Influenced by System Complexity ! 
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Program Availability Requirements Relationships 
Discussion of Proper Requirements With Appropriate Attributes Continued 

Select MTBF of interest, “call to station until launch” (72 hrs.), and failure rate of zero (0) 

• With CLV MTBF of 1000 hours, and CARD requirement of 88% probability of success 
of launch on time, the table below (see chart 25) shows that CLV’s active parts are 
constrained from 1 ,000 to 2,000 = -1780 

• With CARD Availability of 0.98, the calculated MTTR would only be ~1 .5 hours for 
performing any corrective action during the 72 hours prior to launch. 

• However, if probability of success = 95%, CLV complexity must be reduced by -60%, 
i.e., total active parts count are constrained to between 500 and 1000 = -700 

System Complexity (Parts Count (N)) 


System 
Reliability (R) 

(L)=1-R 

40000 

20000 

10000 

5000 

2000 

1000 

500 

400 

300 

200 

100 

50 

25 

0.9500 

0.0500 

100.0000% 

100.0000% 

100.0000% 

100.0000% 

99.9253% 

97.2676% 

83.4701% 

76.3072% 

66.0404% 

51.3248% 

30.2324% 

16.4730% 

8.6069% 

0.9600 

0.0400 

100.0000% 

100.0000% 

100.0000% 

99.9999% 

99.6849% 

94.3865% 

76.3072% 

68.3996% 

57.8527% 

43.7858% 

25.0238% 

13.4112% 

6.9469% 

0.9700 

0.0300 

100.0000% 

100.0000% 

100.0000% 

99.9980% 

98.6700% 

88.4675% 

66.0404% 

57.8527% 

47.6909% 

35.0791% 

19.4265% 

10.2372% 

5.2568% 

0.9800 

0.0200 

100.0000% 

100.0000% 

99.9999% 

99.9253% 

94.3865% 

76.3072% 

51.3248% 

43.7858% 

35.0791% 

25.0238% 

13.4112% 

6.9469%r 

3.5360% 

0.9900 

0.0100 

100.0000% 

99.9999% 

99.9253% 

97.2676% 

76.3072% 

51.3248% 

30.2324% 

25.0238% 

19.4265% 

13.4112% 

6.9469% 

3.5360% 

1.7839% 

0.9910 

0.0090 

100.0000% 

99.9998% 

99.8466% 

96.0836% 

72.6376% 

47.6909% 

27.6750% 

22.8331% 

17.6671% 

12.1553% 

6.2745% 

3.1881% 

1.6069% 

0.9920 

0.0080 

100.0000% 

99.9990% 

99.6849% 

94.3865% 

68.3996% 

43.7858% 

25.0238% 

20.5784% 

15.8694% 

10.8812% 

5.5973% 

2.8389% 

1.4297% 

0.9930 

0.0070 

100.0000% 

99.9958% 

99.3526% 

91.9540% 

63.5052% 

39.5891% 

22.2755% 

18.2578% 

14.0324% 

9.5886% 

4.9151% 

2.4885% 

1.2521% 

0.9940 

0.0060 

100.0000% 

99.9823% 

98.6700% 

88.4675% 

57.8527% 

35.0791% 

19.4265% 

15.8694% 

12.1553% 

8.2773% 

4.2280% 

2.1368% 

1.0742% 

0.9950 

0.0050 

99.9999% 

99.9253% 

97.2676% 

83.4701% 

51.3248% 

30.2324% 

16.4730% 

13.4112% 

10.2372% 

6.9469% 

3.5360% 

1.7839% 

0.8960% 

0.9960 

0.0040 

99.9990% 

99.6849% 

94.3865% 

76.3072% 

43.7858% 

25.0238% 

13.4112% 

10.8812% 

8.2773% 

5.5973% 

2.8389% 

1.4297% 

0.7174% 

0.9970 

0.0030 

99.9823% 

98.6700% 

88.4675% 

66.0404% 

35.0791% 

19.4265% 

10.2372% 

8.2773% 

6.2745%r 

4.2280% 

2.1368% 

1.0742% 

0.5385% 

0.9980 

0.0020 

99.6849% 

94.3865% 

76.3072% 

51.3248% 

25.0238% 

13.4112% 

6.9469% 

5.5973% r 

4.2280% 

2.8389% 

1.4297% 

0.7174% 

0.3594% 

0.9990 

0.0010 

94.3865% 

76.3072% 

51.3248% 

30.2324% 

13.4112% 

6.9469%r 

3.5360% 

2.8389% 

2.1368% 

1.4297% 

0.7174% 

0.3594% 

0.1798% 

0.9998 

0.0002 

43.7858% 

25.0238% 

13.4112% 

6.9469%r 

2.8389% 

1.4297% 

0.7174% 

0.5743% 

0.4311% 

0.2876% 

0.1439% 

0.0720% 

0.0360% 

0.9999 

0.0001 

25.0238% 

13.4112% 

6.9469%f 

3 . 5360 % 

1.4297% 

0.7174% 

0.3594% 

0.2876% 

0.2158% 

0 . 1439 % 

0.0720% 

0.0360% 

0.0180% 


Probability of Success is Highly Influenced by System Complexity ! 
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Program Availability Requirements Relationships 

For MTTR and System Reliability Where MTBF = -1 / In R 


Availability (A) = Mean Time Between Failure (MTBF) / (MTBF + Mean Time To Repair (MTTR)) 

or 

A = MTBF / (MTBF+MTTR) or MTTR = MTBF/(A - MTBF) 

A family of curves can be created for A = 90% to 99.9% with System Reliability (R) = 0.95 to 0.9999 
Then MTTR is calculated for @ each A value 


Availability (A) 


System 

90% 

91% 

92% 

93% 

94% 

95% 

96% 

97% 

98% 

99% 

99.50% 

99.90% 

Reliability 


0.9500 

2.17 

1.93 

1.70 

1.47 

1.24 

1.03 

0.81 

0.60 

0.40 

0.20 

0.10 

0.02 

0.9600 

2.72 

2.42 

2.13 

1.84 

1.56 

1.29 

1.02 

0.76 

0.50 

0.25 

0.12 

0.02 

0.9700 

3.65 

3.25 

2.85 

2.47 

2.10 

1.73 

1.37 

1.02 

0.67 

0.33 

0.16 

0.03 

0.9800 

5.50 

4.90 

4.30 

3.73 

3.16 

2.61 

2.06 

1.53 

1.01 

0.50 

0.25 

0.05 

0.9900 

11.06 

9.84 

8.65 

7.49 

6.35 

5.24 

4.15 

3.08 

2.03 

1.01 

0.50 

0.10 

0.9910 

12.29 

10.94 

9.62 

8.33 

7.06 

5.82 

4.61 

3.42 

2.26 

1.12 

0.56 

0.11 

0.9920 

13.83 

12.31 

10.83 

9.37 

7.95 

6.55 

5.19 

3.85 

2.54 

1.26 

0.63 

0.12 

0.9930 

15.82 

14.08 

12.38 

10.72 

9.09 

7.49 

5.93 

4.40 

2.91 

1.44 

0.72 

0.14 

0.9940 

18.46 

16.43 

14.45 

12.51 

10.61 

8.75 

6.92 

5.14 

3.39 

1.68 

0.84 

0.17 

0.9950 

22.17 

19.73 

17.35 

15.02 

12.73 

10.50 

8.31 

6.17 

4.07 

2.02 

1.00 

0.20 

0.9960 

27.72 

24.68 

21.70 

18.78 

15.93 

13.13 

10.40 

7.72 

5.09 

2.52 

1.25 

0.25 

0.9970 

36.98 

32.92 

28.94 

25.05 

21.24 

17.52 

13.87 

10.29 

6.79 

3.36 

1.67 

0.33 

0.9980 

55.50 

49.40 

43.43 

37.60 

31.88 

26.29 

20.81 

15.45 

10.19 

5.05 

2.51 

0.50 

0.9990 

111.06 

98.85 

86.91 

75.23 

63.80 

52.61 

41.65 

30.91 

20.40 

10.10 

5.02 

1.00 

0.9999 

1,111.06 

988.96 

869.52 

752.65 

638.27 

526.29 

416.65 

309.26 

204.07 

101.01 

50.25 

10.01 


MTTR 


MTBF 
= -1/In R 

19.49573 

24.4966 

32.8308 

49.49832 

99.49916 

110.6104 

124.4993 

142.3566 

166.1662 

199.4996 

249.4997 
332.8331 

499.4998 

999.4999 
9999.5 



Specifying one parameter implies requirements on the other two variables 


Examples: 

Assume the MTBF is 1000 hours (R=0.999), with an 
availability (A) of .98, then the MTTR would be 20.4 hours 
Assume the desired MTTR is -4 hours with an availability of 
.98, then the MTBF would be -199.5 hours @ R of 0.995 
Requirement Development: Use MTBF of 1000 hours 
(R=0.999) and MTTR of 5 hour to support the CTS Lunar 
launch case; therefore, A = 0.995 or 99.5% 


We Must Get This Right for Mission Success 


MTTR Values (Hrs.) 


Program Availability Requirements Relationships 

For MTTR and System Reliability Where MTBF = -1 / In R 


Mean Time To Repair (MTTR) 
Relationship to Availability Requirements 
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MTTR Values in % MTB 


Program Availability Requirements Relationships 

For MTTR and System Reliability Where MTBF = R / 1 - R 


Program Availability Requirements Relationship 
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Program Availability Requirements Relationships 

Probability of Failure Relationship for System Complexity 
and System Reliability Where MTBF = R / 1 - R 

Note: Red Font Cells in Row 4 & 5 are 

Maximum number of failures = 1 or less (r) = I i ~~1 N*L‘t t = i variables and can be changed to meet your 

Failure rate of each system element (L for Lambda) = 1 - R | i ] application's needs. 

A family of curves can be created for Probability of Failure of 2 or More Parts per event with 
System Reliability Values of: (R) = 0.95 to 0.9999 


System Complexity (Parts Count (N)) 
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Probability of a Failure of 2 or More Parts During the Event 



Specifying one parameter implies requirements on the other two variables 


Examples: 

Assume the R=0.999 or less, with an availability (A) of .98, 
then the MTTR would be 1000 x 2.0408% = to -20.41 
hours; however, Event Failure is extremely high relative to 
a given System Complexity. 

Requirement Development: The Reliability-to-System 
Complexity Relationship must be Developed with 
Compatable Requirements to enable Mission Success 


We Must Get This Right forMission Success ) 
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% Propability of Occurence 


Program Availability Requirements Relationships 

Probability of Failure Relationship for System Complexity 
and System Reliability Where MTBF = R / 1 - R 

Failure Event Probability 
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Program Availability Requirements Relationships 

Conclusions 


• The Constellation Program must change and expand the Reliability and Availability 
Requirements by selecting derived values from the Program objectives and include 
requirements for MTBF, MTTR, and Probability of Failure to Launch tied to Total 
System Complexity [Total number of systems and active components, e.g., any 
replaceable component (LRU’s) at the launch site]. 

• The development of attributes required for the Lunar example should consider using 
these active assessment tools in establishing the Availability, MTBF, MTTR and 
System’s Complexity constraints. 

• Desire is to achieve a high probability of launch on time; therefore, if launch isn’t 
achieved on 1 st attempt, the program needs to preserve the 24 hour turnaround 
which then drives the MTTR to 5 hours or less. 

- Therefore, from chart 12, the availability requirement for the CLV must be 99.5% 
= -5 hours 

- Now assume the program’s objective for the CEV is to achieve 208 days or 4992 
hours for its MTBF (equivalent to a Systems Reliability of -0.9998) 

- Therefore, from chart 12, the availability requirement must be -99.9% 
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Program Availability Requirements Relationships 

Conclusions 


• However, when considering the hardware probability of failure of less than 5%, from 
charts 14 & 15 this would suggest choosing the System Reliability value from an 
assessment of the System’s Complexity, e.g., with System Reliability of 0.9999 
(equivalent to a MTBF of 9999.5 hours) for both the CLV & CEV, the total active 
components count should be constrained to -3,300 or less. This assessment allows 
for 1 or less failures per event. Example: Reset tool to 0 failures allowed, this yields a 
system complexity constrained from the -3300 to only -500. 

• MTTR does not change with respect to reliability when expressed in percent of MTBF 
(see chart 13); however, actual MTTR values proportionally increase with system 
reliability values (see chart 12) while holding the Availability value constant, i.e., to 
hold MTTR constant the system reliability must improve to achieve higher availability 
resulting in higher probability of launch success. 

• This “Probability of Failure Relationship for System Complexity and System 
Reliability” can be accomplished using the assessment tools (product of assessment 
on chart 14) to evaluate all systems of the program including the ground systems 
when considering it as a reusable system. 
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Program Availability Requirements Relationships 

Recommendations 


> Establish the probability of launch value, starting at "LCC Call to Station" and ending 
at close of day of launch window, such that the weather constraint of 0.95 becomes 
the driver and not the Flight or Ground Systems hardware failure probability. 

> Revise the CARD requirement for Net Probability of Launch to 0.95. 

> Establish a requirement in the CARD for MTTR for CLV & CEV of ~5 hrs or less. 

> Establish the Ground and Mission Systems reliability requirements and active 
hardware limitations that are compatible with the Program objectives and the revised 
CARD requirements for launch probability. 

> Constrain CEV/CLV/MS/GS System Complexity (See following charts for suggested 
requirements) 


18 


Program Availability Requirements Relationships 

Recommendations - For CEV 

> Accept the Flight Systems hardware reliability values of 0.9998 for CEV (equivalent to 
MTBF of 208 days) 

> Establish the Availability value for the CEV (assuming 0.9998 reliability) to be 99.9% 

Assuming the CARD Baseline : Probability of launch, from "LCC Call to Station" to launch 

> Add new requirement to constrain the total active components count to an equivalent 
-16,500 or less @ the Systems Reliability of 0.9998 for the CEV and with a 95% 
probability of launch. This assessment allows for 0 failures per event while assuming 
a 72 hr. launch period 

If the desire is to broaden the launch period of interest : Probability of launch, from Vehicle 
Stacking to Launch 

> Add new requirement to constrain the total active components count to an equivalent 
-2,575 or less @ the Systems Reliability of 0.9998 for the CEV and with a 95% 
probability of launch. This assessment allows for 0 failures per event while assuming 
a -500 hr. launch site flow period 

> Or, add new requirement to constrain the total active components count to an 
equivalent -17,300 or less @ the Systems Reliability of 0.9998 for the CEV and with 
a 95% probability of launch. This assessment allows for one or less failures per event 
while assuming a -500 hr. launch site flow period 
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Program Availability Requirements Relationships 

Recommendations - For CLV 

> Accept the Flight Systems hardware reliability values of 0.999 for CLV (equivalent to 
MTBF of lOOOhrs) 

> Establish the Availability value for the CLV (assuming 0.999 reliability) to be 99.5% 

Assuming the CARD Baseline : Probability of launch, from "LCC Call to Station" to launch 

> Add new requirement to constrain the total active components count to an equivalent 
-700 or less @ the Systems Reliability of 0.999 for the CLV and with a 95% 
probability of launch. This assessment allows for 0 failures per event while assuming 
a 72 hr. launch period 

If the desire is to broaden the launch period of interest : Probability of launch, from Vehicle 
Stacking to Launch 

> Add new requirement to constrain the total active components count to an equivalent 
-100 or less @ the Systems Reliability of 0.999 for the CLV and with a 95% 
probability of launch. This assessment allows for 0 failures per event while assuming 
a -500 hr. launch site flow period 

> Or, add new requirement to constrain the total active components count to an 
equivalent -675 or less @ the Systems Reliability of 0.999 for the CLV and with a 
95% probability of launch. This assessment allows for one or less failures per event 
while assuming a -500 hr. launch site flow period 


20 


Program Availability Requirements Relationships 


APPENDIX 
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Program Availability Requirements Relationships 

Probability of Failure Relationship for System Complexity & System 
Reliability Where CEV MTBF of Interest = Last 72 hrs to Launch 

Note: Red Font Cells in Row 4 & 5 are 

Maximum number of failures = 1 or less (r) = | o | N*L*t t = i variables and can be changed to meet 

Failure rate of each system element (L for Lambda) = 1 - R | 0.015 | your application's needs. 

A family of curves can be created for Probability of Failure of 0 Parts per event with 
System Reliability Values of: (R) = 0.95 to 0.9999 (CEV @ 0.9998) or 208 days = MTBF 
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Probability of a Failure of 0 Parts During the Event fot This CEV Example 




Specifying one parameter implies requirements on the other two variables 


Examples: 

Assume the R=0.999 or less, with an availability (A) of .98, 
then the MTTR would be 1000 x 2.0408% = to -20.41 
hours; however, Event Failure is extremely high relative to 
a given System Complexity. 

Requirement Development: The Reliability-to*System 
Complexity Relationship must be Developed with 
Compatable Requirements to enable Mission Success 


We Must Get This Right for Mission Success 
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station until launch period of 
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total active parts count to 
-40,000; however, if the 
desire is to provide a 
propability of sucess of 95%, 
the total active parts count 
would be constrained to 
between 10,000 and 20,000 = 
-1650. If the CARD 
Availability requirement (0.98), 
the MTTR would be 1 .5 hours, 
but would relax the parts 
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Program Availability Requirements Relationships 

Probability of Failure Relationship for System Complexity & System 
Reliability Where CEV MTBF of Interest = Last 72 hrs to Launch 

Failure Event Probability for CEV Example & CARD Values 
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Probability of Failure During Any Eve 


Program Availability Requirements Relationships 
Probability of Failure Relationship for System Complexity & System 
Reliability Where CEV MTBF of Interest = Last 72 hrs to Launch 

Complexity and Reliability (MTBF) Influence on Requirements 
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Program Availability Requirements Relationships 

Probability of Failure Relationship for System Complexity & System 
Reliability Where CLV MTBF of Interest = Last 72 hrs to Launch 

Note: Red Font Cells in Row 4 & 5 are 

Maximum number of failures = 1 or less (r) = | o | N*L*t t = i variables and can be changed to meet 

Failure rate of each system element (L for Lambda) = 1 - R | 0.072 1 your application's needs. 

A family of curves can be created for Probability of Failure of 0 Parts per event with 
System Reliability Values of: (R) = 0.95 to 0.9999 (CLV @ 0.999) or 1000 hours = MTBF 
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5.5973% 

2.8389% 

1.4297% 

0.7174% 


weakest component 

0.9970 

0.0030 

99.9823% 

98.6700% 

88.4675% 

66.0404% 

35.0791% 

19.4265% 

10.2372% 

8.2773% 

6.2745%r 

4.2280% 

2.1368% 

1.0742% 

0.5385% 


while assuming 0 

0.9980 

0.0020 

99.6849% 

94.3865% 

76.3072% 

51.3248% 

25.0238% 

13.4112% 

6.9469% 

5.5973%| 

4.2280% 

2.8389% 

1.4297% 

0.7174% 

0.3594% 


failures during the call- 

0.9990 

0.0010 

94.3865% 

76.3072% 

51.3248% 

30.2324% 

13.4112% 

6.9469% r 

3.5360% 

2.8389% 

2.1368% 

1.4297% 

0.7174% 

0.3594% 

0.1798% 

< 

to-station until launch 

0.9998 

0.0002 

43.7858% 

25.0238% 

13.4112% 

6.9469%r 

2.8389% 

1.4297% 

0.7174% 

0.5743% 

0.4311% 

0.2876% 

0.1439% 

0.0720% 

0.0360% 


period of 72 hours. 

0.9999 

0.0001 

25.0238% 

13.4112% 

6.9469%f 

3.5360% 

1.4297% 

0.7174% 

0.3594% 

0.2876% 

0.2158% 

0.1439% 

0.0720% 

0.0360% 

0.0180% 
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% Propability of Occurenc 


Program Availability Requirements Relationships 

Probability of Failure Relationship for System Complexity & System 
Reliability Where CEV MTBF of Interest = Last 72 hrs to Launch 


120 . 0 % 

100 . 0 % 

80.0% 

60.0% 

40.0% 

20 . 0 % 

0 . 0 % 


Failure Event Probability for CLV Example & CARD Values 



Sensitivity to 
Parts Count 

— ♦ — 40000 
- m — 20000 
10000 
— X— 5000 
— * — 2000 
-•-1000 
—1—500 
— - — 400 

300 

200 

100 

50 

— x— 25 


*■ 


f ^ ^ ^ ^ ^ ^ ^ 


Lambda = 1 - R 
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Probability of Failure During Any Even 


Program Availability Requirements Relationships 

Probability of Failure Relationship for System Complexity & System 
Reliability Where CEV MTBF of Interest = Last 72 hrs to Launch 


Complexity and Reliability (MTBF) Influence on Requirements 


120.0% 


100.0% 


80.0% 


60.0% 


40.0% 


20 . 0 % 


0 . 0 % 




CARD 88% Probability 
of Success Area of 
Acceptable Design 


Lambda 

(1-R) 

□ 40000 
fl 20000 

□ 10000 

□ 5000 
B 2000 

□ 1000 
fl 500 

□ 400 
B 300 
fl 200 

□ 100 
□ 50 
B 25 


(L)=1-R 0.0500 0.0400 0.0300 0.0200 0.0100 0.0090 0.0080 0.0070 0.0060 0.0050 0.0040 0.0030 0.0020 0.0010 0.0002 0.0001 

Complexity (Total Parts Count) 
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A History of Designs .. 

Many Choices Exist for Future Missions ■■■ 1st Order Guidance? 



His/Her Selection ? 
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Propulsion System Design Ha s ^A Major In fluence 

In defining a space vehicle architecture, the propulsion system and related sub systems 
choices selected will have a major influence on achieving the goals and objectives. 

• Many propulsion alternatives and choices exist. They provide the means to meet the system 
performance requirements and the greatest opportunity of reaching the desired mission objectives. 

• Recognizing the above, the SPST Functional Requirements Sub-team has drawn on the 
knowledge, expertise, and experience of their members, to document information (insight) that 
will effectively aid the “Architectural Concept Developer” in the beginning of the design process 
to understand the differences between the alternatives. 

The propulsion system “choices” with their “pros & cons” are presented in 5-major groups. 

1. System Integration Focused on the requirement for safety reliability, dependability, maintainability and 
low cost. 

2. Non Chemical Propulsion 

3. Chemical Propulsion Propellant and Combustion 

4. Functional Integration Focused on the many propulsive or closely associated functions and the rocket 
combustion cycle 

5. Thermal Management 
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System Integration Approach - Focus on Safety, Reliability, 
Dependability, Maintainability, and Low Cost 


Successful system integration requires a strong systems engineering process & 
subsystem knowledge-base. The design choice knowledge-base is grouped in 7-areas. 


1 . Vehicle configuration of propellant tanks (e.g. placement of tanks: parallel, toroidal/nested) 

2. Propulsion system engine propellant feed technique (press-fed, pump-fed, electric, reciprocating) 

3. Propellant transfer pump location (pump integration w/tanks, w/TCA*, aft-structure) 

4. Functionally optimizing propulsion components vs. traditional stand-alone rocket engine 
(turbopump w/TCA, Separated TPA* & TCA, IVHM & EHMS, Integrated HM) 

5. Main rocket engine start considerations (fast, stepped, or soft-steady ramp) 

6. Number of main rocket engine nozzles and their placement (vectoring along axis, fixed w/ACS) 

7. Structural design of aft end of vehicle (closed base area w/Heat shield, aerodynamically 
integrated) 


*TCA=Thrust Chamber Assembly 
TPA=Turbopump Assembly 
HMS=Health Management System 4 

ACS=Auxiliary Control System 
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System Integration Approach - Pros & Cons Example 


Architectural 

Candidate 

Propulsion 
System Choice 

Pro’s 

Con’s 

System Integra 

tionfor Safety, Ri 

ihability, Dependability, Maintainability, anc 

I Lon Cost Considerations (Grouping) 


configuration of 

propellant tanks 


forward & fuel tank 
aft — 


performance loss when thrusting throu^i the CG of the 
vehicle with engines opposing each other. Also 
provides peeler control authority of the vehicle at a 
given engine gimble angle vfom in need of steering. 
However, if engines are mounted on a sin^e plane and 
thrusting throu^i the CG,the fligjut attitude angle is 
less with respect to the vertical axis of the vehicle and 
again the gimble angles required for control are less 
with the greater moment arm length. 



ge^emg andrasulfog wterhamm er loads dirrig ground 
semciig ardvfoide pogo inflict, and engfoe tufoopunp and 
feed system thermal candiioningfor enghe start. All three of 
these candiionsreqiire active stf)-systems to accommodate, 
e g,pog» suppression system, lox anti-geysering system, and a 
prcpeHait thermal ccnditicnrig system. In addifonto foe above 
added srb-systems,the semiring process is much longer and 
requires process ccntrolto maintain a safe vehicle, eg^lox 
chil-dcwntD remove the sensible he*. of the enghe mass - 
tufoopumpto ^oidmuncortrolMge^eriiii^b^ a 
slew fill badiig of the feed sytemto avoid damage of the tarfe 
outltf. anti-vortex liariware; andpossible feed system drain- 
bad: c<xuMiXLhgjustbefora enghe start. 

These constrairts compromise holdtime flexfoiltyfollOTririg 
ieplaiish compile and re quire active systemfonicticimgwifo 
fhilttoleranceto avoid bss ofvehide. Acor^trahtis also 
placed onthe gomdlox-semiting sytemto condition or avoid 
warm lox temperatures artwo-phase flow it the flgjtvehicle 
interface at all times. These above addedsub systems add 
considerable hardsvare, added wei^tt, adde d non-re anrhg 
hanivare cost, ground support, infrastructure, consumables, 
considerable maintenance burdm/cost andtime and sustaimg 
engine ering burdenfc ost . 

vehicle piopellaVtmhs cany foe badforou^ifoe base, foe 
ltank wilbe requiredto hare the strmghinass to sipport 
bxtarh resulting fa added weffit. 
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NO N-Ch emical Propulsion Systems - Attributes & Characteristics 

These propulsion systems are optimally designed for “In-space” or “Vacuum Conditions” and 
are “power limited” instead of “chemical energy limited” 

The design choice knowledge-base is grouped into 4- areas with further delineation. 

1 . Nuclear (fission) energy powered propulsion 

a) Nuclear Core Heats Low MW* Fluid & Expands Row Supersonically via a Nozzle 

b) Nuclear Core Heats Working Fluid to Drive a Power Conversion Unit for EP* Thruster 

c) Hybrid Nuclear Performs Both of the Above at Different Phases of Mission 

2. Solar energy powered propulsion 

a) Typical PVA Drives EP Thruster, Photon-driven Sail, Solar Energy Used Like 1-a Above 

3. Propulsion thrusters 

a) Hall Effect Electrostatic, ION, Arc-jet Electrothermal, Resistojet Electrothermal, MPD, Cold-gas 

4. Tether powered propulsion 

a) Electrodynamic-based to Drive an EP or Like Mag-sail, Momentum Exchange Propulsion 
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NON-Chemical Propulsion Systems - Pros & Cons Example 


Architectural 

Propulsion 

Pro’s 

Con’s 

Candidate 

System Choice 




Non- Chemical Propulsion Considerations (Grouping) 


1. Nuclear (Fission) 
Energy Powered 
Propulsion 




Nuclear Thermal 
Expansion 



2 Solar Energy 
Powered Propulsion 



Nuclear Electric with 
Thrusters 


Nuclear Bi-Modal with 
Thrusters 


Solar Electric with 
Thrusters 


Solar Sails 


High performance (Isp) (> 850 sec Isp, Thrust 
> 1000 Ibf. Provides the high thrust of chemical 
systems but at 2X the Isp performance. Has 
less complexity in terms of mechanical systems 

than Nuclear Electric Propulsion (NEP). 

Very high performance (Isp) with major 
increases in payload fraction for planetary 
orbital, solar system, and possible interstellar 
missions (Isp 3,000- 1 0,000, Thrust 0 .002 to 
0.5 Ibf). Planetary trip time decreases compared 
to all chemical. Potential to eliminate planetary 
swing-by requirements and increase payload 
delivery as well as decrease trip time. 


High performance (Isp) coupled with very high 
NEP Isp. Can deliver high thrust for earth 
escape with a short thrusting time reducing 
spiral out trajectory time of NEP. Uses NEP 
thrusters by using fission reactor as a power 
source for electric thrusters after planetary 
escape. Planetary trip time decreases compared 
to all chemical. 


Mature technology that is mostly a passive 
system with high dependability and low cost. 
Flight proven with Deep Space 1 spacecraft. 


Concept choice is mostly a passive system, but 
limited to high earth orbit and beyond. 


Safety major concern and difficulty to perform the 
DDT&E (except very small scale below ground level) 
and to perform the ETO operations. Proven at prototype 
level only and politically unattractive due to release of 
fission particles m exhaust 


No flight experience and many operational unknowns 
associated with this technology. Additional fluids and 
complex systems will challenge safety, mission 
reliability, and cost goals 


This choice has all the CON’s of the two choices above, 
except the size will allow the DDT&E to be performed 
underground on earth. 


Susceptible to space debris causing reduced performance. 
Limited to bw performance/reasonable size. Power 
available diminishes with 1/R- relative to moving away 
from Sun. 


Very large structure and travel speed very sbw No flight 
experience and bw technobgy maturity Material 
strength/density major challenge and plasma sail 
technobgy approach maturity even less mature 
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Chemical Propulsion Systems - Attributes & Characteristics 


These propulsion systems are optimized relative to a synergistic approach within several 
multi-disciplinary design functions : 

Examples : Chemistry, Thermodynamic, Mechanical Design, Materials, Structures, Controls, 
Performance Analysis oxidizers: 


The design choice knowledge-base is grouped into 4- areas. 

1 . Choice of propellant type 

2. Choice of propellant by density or performance considerations 

3. Choice of rocket engine combustion chamber/nozzle cooling 

4. Mono-propellant vs. bipropellant propulsion system 


^Liquid Oxygen (LOX), O2 

Nitrogen Tetroxide, N2O4 

Nitrous Oxide, N2O 

Hydrogen Peroxide , H2O2 

Hydrogen Peroxide ( 95 % Concentration), H2O3 

*Oxygen Difluoride (FLOX), OF2 

FUELS: 

^Liquid Hydrogen, (.(hfe) 

^Methane, CH 4 
^Propane, C3H8 
Kerosene, RP -1 
Ethyl Alcohol, C2H5OH 
Methyl Alcohol, CH 3 OH 
MonoMethyl Hydrazine, MMH 
Hydrazine, N 2 H 4 
Ammonia, NH 3 

Unsymmetrical DiMethyl Hydrazine (UDMH), (CFh^NNH 
Aniline, C 6 H 5 NH 2 


* CRYOGENIC 
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Chemical Propulsion Systems - Pros & Cons Example 


Architectural 

Propulsion System 

Pro’s 

Con’s 

Candidate 

Choice 




Propellant & Combustion Considerations (Grouping) 

8. Choice of 



Have ~ 40 years experience safely handling 
NBP propellants in support of servicing and 
flying launch vehicles. Its mass volume 
relationship is a function of atmospheric 
pressure; therefore its flight mass is attained 
with a fixed passive measuring system. They 
provide very hi^i performance. 



Greatest handling concern for fuels are leaks and 
potential fires, therefore, requires leak free designs (all 
welded and avoidance of dynamic seals where ever 
possible) or very tight process verification practices 
(verify leak ti^it). Also LH2 has a very broad 
flammability and explosive range which requires an 
operational monitoring and corrective action system to 
maintain safe operations. Closed compartments are to be 
avoided by desigi and if exist must be either pressurized 
or purged to maintain inert and safe environment. L02 is 
impact sensitive with a very small amount of 
hydrocarbon, therefore, requires all surfaces that it might 
come in contact to be ultra clean. Proper clothing must be 
used when handling to avoid cryogenics bums. All small 
appendages and filters that could contain water vapor or 
gas contaminants must be removed by purging or 
evacuation to avoid freezing blockage or chemical 
contamination. L02 is of high density and is subject to 
geysenng and water hammer from elevation and 
dynamics. 
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Design Choices Relative to Functional Integration Considerations 


The functional integration considerations design choices covers : 


The engine thermodynamic cycles, control approaches for ascent and in-space, and the 
issues of integrating the sub-systems or trying to couple functionally similar sub-systems 
together that need to operate concurrently and in isolation. 


The design choice knowledge-base is grouped into 4- Areas. 

1 . Rocket combustion cycle choice driven by functional 
integration 

2. Choice of vehicle guidance and control steering (ETO) 

3. Choice of vehicle guidance and control steering (In-Space) 

4. Integrating propulsion, power, and thermal management 
functions vs. stand alone 



Example : SSME Cycle 
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Functional Integration Considerations - Pros & Cons Example 


Architectural 

Candidate 

Propulsion 
System Choice 

Pro’s 

Con’s 

Functional Integration Considerations (Grouping) 

Rocket combustion 
cycle choice driven by 
functional integration 





Bb 

-Staged Combustion 
cycle drivenby 
performance efficiency- 

1 lus cycle develops a high efficiency 
combustion process, but is more complex than 
the gas generator cycle. The Shuttle SSME uses 
this cycle; therefore, we have considerable 
experience with it , however, the maturity of 
this cycle towards being hi^ily dependable, 
long life, and low operating cost is very low 
towards being reusable . The Russian engine 
technology has use this cycle extensive Vi 
however, their application is for only 
expendables. 

The maturity of this cycle towards being highly 
dependable, long life, and low operating cost is very low. 
The hardware environments ofthis cycle are quite 
extreme making it difficult to achieve along life and very 
dependable reusable product, which would accommodate 
a low cost operation. 


|P> 

— Expansion cycle 
driven by long 
life/dependability- - 

Unis choice is inherently robust in comparison 
to others and the expected dependability would 
be much higher also. Forthe above reasons the 
expected recurring cost would be much lower 
and the resulting responsiveness ofthe space 
transportation system would also be much 
higher. 

1 his cycle has not been used on a reusable engme and has 
only been demonstrated in thrust levels suitable for upper 
stage engines. The scale-up ability of this cycle is limited 
to creative ways of obtaining the required heat to drive 
the cycle. Our experience with this cycle is limited to the 
RL-10 and its derivatives. 


y\1 

—Gas generator cycle 
driven by simplicity 
and size flexibility— 

We have a large experience base using this 
cycle, but the applications were all expendable. 
This choice is less complex than the 
combustion cycle and can accommodate a 
single turbine drive ofboth propellant pumps 
reducing the parts count . 

I his cycle is not as efficient as the combustion cycle. The 
hardware environments of this cycle are more extreme 
than the expansion cycle. This makes it difficult to 
achieve a long life and very dependable reusable product, 
which would accommodate a low cost operation. 

P 1 v | at two tlmM during fill 

—Pulse Detonation 
Combustion— 

Less hardware and higher thrust to weight 
make this choice attractive, but the dynamic 
demand on the propellant supply valves and the 
injector environment causes concern for 
re liability /dependability and long life forthe 
reusable system application. 

No flight experience and the dependability/life issues of 
propellant supply valves and injectors operating in this 
harsh environment give unknown limitations on 
reusability -application and the resultant life cycle cost. 
Combustion noise may became a concern with this 
choice. 

I 


c 
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Design Choices Relative to Thermal Management Considerations 


The thermal management considerations basically have been grouped in relationship to : 

- The integration or non-integration of the propellant tanks and the “airframe” and how this 
affects the propellant feed system and the structure 


- The methods used for controlling the internal and external thermal environment for 
cryogenics propellants, reentry heating, gas purging, heat energy recovery and how this 
affects the propellant feed system and the structure as well as the operability, safety, and 
cost 


The design choice knowledge-base is grouped in 2- 
Areas. 

1. Integral propellant tank and structure vs. tank and 
aero-shell 

2. Cryogenic tank thermo-insulation considerations 
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Thermal Management Considerations - Pros & Cons Example 


Architectural 

Candidate 

Propulsion System 
Choice 

Pro’s 

Con’s 


Thermal Management Consideration (Grouping) 

Integral propellant 
tank and structure 
vs. tank and aero- 
shell 





—Traditional integral 
tank /structure — 

Main propulsion tank/integral structural choice 
used on STS, but as an expendable design This 
choice eliminates the safety requirement to 
monitor and control by purge the entrapped 
areas caused by separate tank and shell design 
Therefore this choice eliminates safety systems 
that results in higher system safety and lower 
life cycle cost . Results in a lighter overall 
design solution for increased performance 
while also resulting in the lowest life cyck cost 
option. 

To support the reusable design approach the tank skin 
must accommodate the propellant temperatures and the 
re-entry heat ing environment. These requirements pose a 
challenge to the designer when not allowing a purge 
system to be apart of the solution 


—Wing tanks /aero shell for 
vehicle lift— 

Would accommodate change out of tanks when 
needed for the reusable concept. Reduces the 
sensitivity ofbalancing the thermal 
environments of the propellant and the re-entry 
heating. 

Adds requirement far safety monitoring system and safety 
control systems for both explosive potential and for 
personnel maintenance when required. Added support 
systems lower the reliability, safety, and add large ground 
infrastructure support. These all result in increased life 
cycle cost . Also this results in the functional verification 
requirement of thermal insulation parameters between 
flights. Performance maybe less with this choice, as the 
dry weight will most likely increase. 

Cryogenic tank 
the imo - insulat ion 
considerations 





— Internal tank insulation 
far cryogenics thermal 
control and external 
insulation for re-entry 
heating structural control-- 

Provided the design contains margin-robust, 
this choice provides simple passive approach to 
a complex design concern. With a minimum 
quantity of I VHM, this choice should result is a 
low life cycle solution. 

Unless the designtechnology is very mature, the internal 
insulation could became an operational nightmare . Have 
experience with internal insulation for the expendable 
application (SIV & SIVB stages of Saturn vehicle). 


--Complex purged 
composite insulation for 
total heat transfer control-- 

Designer may produce the lightest weight 
design? Total insulation external oft he 
structural substrate, which should reduce the 
need for tank entry. 

this choice will require an added flight support system 
(GHe purge system like Centaur) and its ground support 
infrastructure driving up the life cycle cost . We have no 
experience with this choice for reusable applications. 

I VHM for this concept is also unckar. 
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SUMMARY 


OBJECTIVE OF PRO’S & CON’s PRODUCT 

• To develop a guide to help the “Architectural Concept Developer” in the 
beginning of the design process to understand the differences between 
most of the alternatives they would encounter. 

CAVEATS 

• The Information in the Pro’s & Con’s table should be evaluated 
independently and will vary when considered in specific combinations. 

• Selection of subsystem elements must be optimized at the systems level 
using a multi-disciplined Systems Engineering process that permits a 
focus on multiple attributes and not just performance 

• Finally, the Technology Readiness Level and design risk (Cost, 
Schedule, Safety) must be determined for all design choices !! 
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